Code Security

Connect your GitHub, Bitbucket or GitLab 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, a Bitbucket workspace or a GitLab group 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.

Supported source code providers

Code Security connects to the cloud editions of the three most used providers. The table shows what each connection asks for and how it behaves, so your security team can approve it before anyone connects.

GitLab offers no permission narrower than api for adding a webhook, so that is what the application asks for; WASViking uses it only to list the projects and to manage the push webhook it adds to each monitored project. Every permission in the table is the minimum each provider allows for reading code and receiving push events; on GitHub, Members: read is used only to confirm that whoever connects an organization owns it.

GitHub Enterprise Server, Bitbucket Data Center and Server, self-managed GitLab and Azure DevOps are not supported today. For code hosted there, the pipeline gates run dependency and secret checks from your own CI.

Supported languages

• Static application security testing reviews Python, JavaScript, TypeScript (including JSX and TSX), PHP, Ruby, Go, Java, Kotlin, C#, Scala, Groovy, Rust and Elixir. Route handlers are recognized whether the framework declares them with annotations, decorators, attributes, router calls or inline registrations such as ASP.NET minimal APIs.
• AI / LLM security covers the same languages and follows imports between modules in JavaScript, TypeScript and Python to complete each flow.
• Dependency analysis reads npm, pip, go, composer, Maven, gem and pub manifests and lockfiles.
• Secret detection reads every text file in the repository, whatever the language.

To spend the review on the code that handles requests and enforces access, the SAST review leaves out tests, documentation and examples, build output, vendored and third-party code, migrations, static assets and minified or bundled files.

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. It also reads what the application review skips on purpose, test suites, fixtures, helpers, documentation and tooling, for credentials written into the source, personal data used as test material and hooks that bypass a security control of the application under test; see Source Exposure below. The GitHub Actions workflows of the repository go through the CI/CD pipeline checks.
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.

Source Exposure

A test suite is source code too, and it holds what application code is careful not to: the password of the QA account it signs in with, the static token it sends to an internal endpoint, the identifiers it uses as test data, and the mechanism it relies on to get past a captcha or a one-time code. Those lines are committed, cloned by every developer and indexed by every tool with access to the repository. The Source Exposure review reads them.

How it works. Deterministic detectors walk the whole clone, test directories included, and propose candidates: a literal assigned to a secret-shaped name in code, configuration, environment files or a documentation table with a password column; an identifier that passes its own check digits (CPF, CNPJ, payment card number by Luhn) and is not a known test value; a line that names a security control (captcha, MFA, OTP, verification code, authentication) next to a bypass, skip, override or retrieval cue; the application's own signing secret (session, cookie, JWT, Django and Flask SECRET_KEY, Rails secret_key_base, Laravel APP_KEY) written as a literal, whatever its value. Placeholders, templates and values that a test sends on purpose to be rejected never become candidates, except for the application's own secret, where a value such as dev or changeme is the weakness itself. The review then confirms or rejects each candidate from the surrounding code and explains the confirmed ones. Values are masked before they reach the review and never appear in evidence; what you see is the masked value and the file and line.

A bypass mechanism used from sixty page objects is one finding, anchored on the file that documents or implements it, with the number of files that use it. A credential keeps its identity across scans by value, so a rotated value is a new finding and the old one closes.

Repositories made of tests. WASViking profiles every clone: how many source files it holds, how many live under test directories, which test runners the manifest names. A repository that is a test automation suite is labelled as such on the Code Security page, because its application review reads little by design (handlers do not live in test directories) and the Source Exposure review is the one that covers it.

Backend data access

A growing number of applications have no server of their own: a single page in the browser talks straight to a backend-as-a-service (Supabase, Firebase, Appwrite, PocketBase, Hasura, Parse) with a public key that ships inside the page. In that model the access boundary is the backend's policy layer (row level security, security rules), and the only thing the client code can show is what it asks for and whether it ever signs a user in. WASViking reads that.

How it works. The discovery is offline: it lists the tables, views, functions, collections and buckets the client reads and writes, every sign-in or session call, and the keys found in code and configuration, telling a publishable key (expected in a page) from a service key (never expected there) by its shape and, for a JWT-shaped key, by its role claim. A remote function counts as a write when its name says so (save, close, delete and their Portuguese and Spanish equivalents). One review per backend provider then reads the excerpts around those calls and answers what is reachable with the public key alone. A user chosen from a list inside the page, a name typed into a form or a role read from the data itself is not a session: the backend still sees the anonymous role.

These findings live in the same access control family as the application review, so they count in the SAST tile and open the same evidence panel: the backend, the resources covered, the operations, what the client shows about sessions, the kind of data and the files involved. One finding per backend and class, anchored on a call site, keeps its identity across scans whatever line the call moves to. A sign-in flow that gates the calls closes it on the next scan.

What the review cannot see is the backend's own policies. A finding here says the client gives the backend no user to distinguish; whether the policies compensate is the question to answer on the backend.

Upload a project (.zip)

Not every codebase sits in a provider WASViking connects to: a repository on another SCM, a copy from an air-gapped network, a third-party project you are assessing, or a trial where nobody wants to grant an account yet. For those, send the project as a zip. On the Code Security page, Upload a project (.zip) asks for a project name and the archive; findings and reports are filed under that name, and uploading a new version under the same name re-scans the same project with the same stable finding identities.

What happens to the archive. The browser sends it straight to private object storage under a signed, single-object, size-capped authorisation; the portal never relays the bytes. The scan worker downloads it with a byte cap, unpacks it in the run's isolated workspace and runs the same engines it runs on a clone. Nothing inside the archive is executed. The archive is deleted when the run ends, whatever the outcome, so a new scan needs a new upload. An uploaded project has no cadence and no push trigger; every upload is one manual run.

What is refused or ignored. A password-protected archive, a compression method other than the standard ones, an entry that tries to write outside the project folder, an archive that expands beyond the accepted file count or unpacked size, and anything that is not a zip fail the run with a clear reason. Links, device files and version-control folders (.git and the like) inside the archive are never materialised. Files are written without execute permission.

Uploaded projects count toward the monitored repositories of your plan.

CI/CD pipeline checks

The GitHub Actions workflows of the repository are checked, without a model, for the pipeline weaknesses that turn a pull request or a comment into code running with the repository's secrets.

These checks are exact, so a finding closes after one clean review of the same workflow file.

Limits and what is not scanned

• Coverage is stated, not implied. The repository row and the report say how many source files the latest scan read for access control, against the total the clone holds, and label a test automation repository as such. "No SAST findings" with a small share of files read means the review found nothing in what it read, not that the whole tree was read; coverage widens on successive scans.
• CI/CD checks cover GitHub Actions workflows. Bitbucket Pipelines and GitLab CI configurations are not checked yet.

• Uploaded projects have no git history. Secret scanning of history and push-triggered scans need a connected repository.

• Default branch only. Other branches and pull or merge requests are not scanned.

• Repository size. Repositories up to 2 GB are cloned; a larger one is not scanned and its run says why.
• Review budget per scan. Each scan reviews up to 50 source files with SAST. Files with an open finding come first and the rest rotates across the repository, so coverage grows with successive scans.
• Git history. Secret scanning of the full history of the default branch is available on plans that include it, switched on per repository.
• Cloud editions only. See the providers above.

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, broken authentication (the handler that authenticates grants an identity without verifying a credential, or a sign-in or single sign-on callback that never checks the account is active), methods a dispatcher exposes by convention without an authorization check of their own, request-controlled method or function dispatch without an allowlist, path traversal or file inclusion from a request-controlled path, 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; the Source Exposure family covers hard-coded credentials, personal data in source and security control bypass hooks; the CI/CD pipeline family covers pull request target checkouts, expression injection, write-all permissions and unpinned third-party actions. New classes are added as the analysis grows.

What you see

• AppSec → Code Security: the fleet view. A header with the monitoring coverage (repositories monitored against the ones the connections granted, with the connections behind them) and the actions of the page; eight indicator cards under Security overview: repositories granted, repositories monitored, open findings with the severity bar, WASViking SAST Findings (access control, backend data access, source exposure and CI/CD), AI / LLM Security with how many repositories use AI, components tracked, runs this month and plan allowance in use, each explained on hover and in About the indicators. The inventory offers the views All, Monitored, With findings and Highest risk (the newest SBOM score, highest first) over the filters by name, provider, origin, coverage and findings, with Clear filters as soon as one is on. One row per repository in two bands: the facts (the repository with its branch, visibility, account and origin, the Monitor and Git history switches, the last scan with the commit that was scanned, components, open findings by severity, the risk score and the actions), then the WASViking SAST and AI / LLM Security details: the SAST findings by class with when the code was last reviewed and how many of the repository's source files the latest scan read (a test automation repository is labelled as such), 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. Compact view folds the details behind a chevron and is remembered in the browser; on narrow screens every row becomes a card. Export CSV downloads the inventory with the filters in use, every page at once. 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, Source Exposure, CI/CD pipeline and AI / LLM sections, the coverage of the latest scan and the AI usage profile, for a code owner or an auditor.
• Software inventory: components under Exposure → Inventory → Software Bill of Materials, daily advisory matches under Exposure → Inventory → Supply Chain Intel, secret submissions under AppSec → 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 token that is dropped when the clone finishes: on GitHub, an installation token limited to that one repository; on Bitbucket and GitLab, the access token of the authorization, renewed automatically, which WASViking uses only for the repositories of the connected workspace or group.
• Clones use https to github.com, bitbucket.org or gitlab.com 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 or a GitLab group the connection is accepted only from an owner, so a member who can see the code 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

• AppSec → Code Security: coverage, results and runs.
• Admin → System Settings → Connected Repositories: the provider connection, what it granted, sync and disconnect.
• Findings: triage, with the repository and category filters.
• Admin → User → Profile & Plan Usage → Subscription → Repositories: allowance and usage.

Frequently asked questions

Does Code Security work with GitHub, Bitbucket and GitLab? Yes, with GitHub.com, Bitbucket Cloud and GitLab.com. Each provider is connected once from Admin → System Settings → Connected Repositories, and all of them get the same analyses, triggers and findings.

Can I connect GitHub Enterprise Server, Bitbucket Data Center or a self-managed GitLab? Not today. Code Security reaches the cloud editions only. The pipeline gates cover dependencies and secrets from your own CI meanwhile.

Which branch is scanned, and are pull requests scanned? The default branch of each monitored repository. Pull and merge requests are not scanned.

Can I connect more than one workspace or group? Yes. Each Bitbucket workspace or GitLab group is its own connection, and a GitHub App installation covers the repositories you grant to it. Your plan counts monitored repositories, not connections.

Why does the GitLab application ask for the api permission? It is the only GitLab permission that allows adding a webhook, which is how a push triggers a scan. WASViking uses it to read the project list and to manage that one webhook, and it never changes code or settings in your projects.

What happens to the code after a scan? The clone and every intermediate file are deleted when the run ends. WASViking keeps the findings with their evidence, the component list, redacted secret evidence and the run record.

Set up

Follow Set up Code Security: connect GitHub, Bitbucket or GitLab, 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.