Code Security

Connect your GitHub or Bitbucket repositories and let WASViking assess the source continuously with static application security testing (SAST), AI / LLM security review, dependency analysis, secret detection and SBOM generation, with every risk and its remediation context in one place.

WASViking^® Code Security is the Application Security hub for the source code behind your applications. You connect a GitHub account or a Bitbucket workspace once and choose the repositories to monitor. From then on the platform clones each default branch on its own and runs four analyses on it: static application security testing (SAST), dependency analysis, secret detection and SBOM generation. Everything it finds lands in Findings with the same lifecycle, risk score, SLA and alerting as the rest of the platform, and the repository becomes an asset in your inventory, like a target. No pipeline change is required.

The problem it solves

Most code security tooling lives inside the pipeline. Repositories without a pipeline, legacy services nobody deploys any more and the internal tools that never got a CI job receive no coverage at all, and they are often the ones holding the oldest code. Even where a pipeline exists, each tool reports into its own console, so the team triages dependency alerts in one place, leaked secrets in another and never sees the weaknesses in its own application logic, which no dependency database and no external scanner can reach.

Code Security turns that into one motion. WASViking reads the code, correlates what it finds with what your scans already know about the running application, and files the result where your team already works: the Findings queue, the risk score, the alerts and the tickets.

What runs on every monitored repository

1. Static application security testing. WASViking reads the application source itself. Automated code discovery ranks the files that matter for security, such as routes, controllers, request handlers and authorization code, and the analysis reviews them for weaknesses in how the application enforces access and protects its users. Every weakness is reported with source-level evidence: the file and line, the route and the parameter involved, why it is exploitable, a concrete attack scenario and the fix for that exact code. Each reported line is verified against the real file before it reaches you; anything the analysis cannot ground in the code is discarded. Every file carrying an open finding is reviewed again on each scan, and the remaining review budget rotates across the rest of the repository, so coverage widens with successive scans. The same review covers the code that puts a language model to work; see AI / LLM Security below.
2. Dependency analysis. Dependency manifests (npm, pip, go, composer, Maven, gem, pub) become a component list matched against OSV and the CISA KEV catalogue, with drift detection against the previous scan of the same repository.
3. Secret detection. The working tree, and the git history of the default branch when your plan includes it and you switch it on for that repository, are scanned for hard-coded credentials. Evidence is redacted before it is stored.
4. SBOM generation. Each scan produces a CycloneDX SBOM for the repository. It feeds the daily re-check of Supply Chain Intel and can be exported as a signed SBOM Evidence Bundle.

AI / LLM Security

Teams put language models into applications faster than security learns about it: a support chat, a copilot inside the admin, an agent that can refund an order, a retrieval layer over internal documents. Code Security treats that code as part of the same SAST review, with the same question it already asks about access control: can someone who should not, reach something they should not?

On every scan WASViking first discovers where the repository uses AI, without calling any model. It records the providers and gateways the code talks to, the agent and orchestration frameworks, how many agents and tools are defined, whether documents are retrieved into the prompt (RAG), whether vector stores or MCP servers are in play and which model names the code references. That profile appears on the Code Security row and in the run history, so you know where AI already lives in your systems before the first weakness is found.

Then the review reads each file that talks to a model together with the modules that complete its flow, such as the route that feeds the agent and the module that defines its tools, and reconstructs the trust path: where untrusted content enters, how it reaches the prompt, what the model's output can reach on the way out and whether a check sits in between. System instructions are trusted. The user prompt, retrieved documents, fetched pages, inbound email, uploaded files and webhook payloads are untrusted. Tools and actions, databases, internal APIs, secrets, payments, account operations and other tenants' data are sensitive. A path from untrusted to sensitive with no adequate control in the middle is a finding.

Severity follows what the path reaches, not the presence of a prompt. User content reaching the model with nothing downstream is medium. A path that reaches sensitive data is high. A path that can trigger a tool or action with no gate in between is critical. That keeps a chat endpoint that only echoes the model from being rated like an agent that can refund payments, and it is what makes the finding worth a developer's attention when it is critical.

The evidence panel shows the class and its OWASP Top 10 for LLM Applications mapping, the entry point, the untrusted input, the model call, the sensitive operation, whether an authorization check was found, the trust path drawn step by step, why it is exploitable, an attack scenario, the code excerpt with the flagged line and the fix for that exact code. Every reported line is verified against the real file, and the same file-and-handler identity keeps one risky path one finding across scans.

The review never sends prompts to your model, never calls your providers and never executes the repository. It reads source only.

Findings that behave like findings

• Stable identity. The same weakness in the same place is one finding across scans, even as line numbers move. It reopens on regression and resolves on its own once two consecutive reviews of the same file no longer find it.
• Same lifecycle as everything else. Severity, risk score, SLA clock, audit trail, assignment, webhooks and ticketing work exactly as they do for a DAST finding. A fix is measured the same way whether the weakness was found in traffic or in code.
• Evidence a developer can act on. The WASViking SAST Findings panel on a finding shows the weakness class, the file and line, the route and parameter, a plain explanation of why it is exploitable, the attack scenario, the remediation and the code excerpt with the vulnerable line highlighted. The access-control family it reports today includes IDOR, BOLA, BFLA, missing authorization checks and clickjacking; the AI / LLM family covers prompt injection, indirect prompt injection, unsafe tool execution, sensitive data sent to the model and cross-tenant context. New classes are added as the analysis grows.

What you see

• Application Security → Code Security: the fleet view. Tiles for repositories granted, repositories monitored, open findings, WASViking SAST Findings, AI / LLM Security with how many repositories use AI, components tracked, runs this month and plan allowance in use. One row per repository with the Monitored and Git history switches, the commit that was scanned, components, open findings by severity, the SAST findings by weakness class with when the code was last reviewed, the AI / LLM findings by class with the AI usage profile of the repository (providers, frameworks, agents, tools, RAG), a Drift marker when the dependency set changed and KEV when a finding is on the CISA catalogue. The Runs panel keeps the history of every scan with its trigger, branch, commit, duration and what it found.
• Findings: filter by repository and by category to triage, or by the OWASP Top 10 for LLM Applications entry. Every SAST finding opens with its evidence panel.
• Repository report: a PDF with every open finding of one repository, by engine, including the SAST and AI / LLM sections and the AI usage profile, for a code owner or an auditor.
• Software inventory: components under Inventory → Software Bill of Materials, daily advisory matches under Inventory → Supply Chain Intel, secret submissions under Application Security → Hard-coded Secrets.

Alerts and tickets

New and reopened findings follow your notification rules like any other finding: Slack and Teams, Webhooks, Jira and ServiceNow.

Safe by design

• The clone happens in an isolated, short-lived workspace on a dedicated worker. Nothing from the repository is ever executed.
• Provider credentials never reach your browser and are stored encrypted. Each run uses a short-lived, repository-scoped token that is dropped when the clone finishes.
• Clones use https to the provider only, with prompts, LFS and submodules disabled and a size ceiling per repository.
• The clone and every intermediate file are deleted at the end of the run, also when the run fails or times out. Only derived data stays: findings with their evidence, the component list, vulnerability matches, redacted secret evidence and the run record.
• On a GitHub organization the connection is accepted only from an owner, so a member who can see an installation cannot bind your organization to another tenant.

Plan availability

Code Security is included on the Pro plan and above; a partner or our team can enable it on other plans. Each monitored repository counts one unit against the plan allowance, whatever its size and however often it is scanned. Every monitored repository is scanned at least once per interval (Pro every 24 hours, Business every 4 hours, custom on Enterprise) and right away on a push to the default branch when the interval has elapsed. Admins and Managers connect providers and choose what to monitor; Analysts read the results.

Where it lives in the portal

• Application Security → Code Security: coverage, results and runs.
• Settings → System Settings → Connected Repositories: the provider connection, what it granted, sync and disconnect.
• Findings: triage, with the repository and category filters.
• Account → Subscription → Repositories: allowance and usage.

Set up

Follow Set up Code Security: connect GitHub or Bitbucket, switch Monitored on for the repositories WASViking should read, run the first scan and let the cadence take over. Then walk through Triage your first SAST finding to read the evidence, fix the code and confirm the finding closes on its own.