Your code is an attack surface. Assess it the way you assess what is running.
Connect your GitHub or Bitbucket repositories once. WASViking clones each default branch on its own and runs static application security testing, dependency analysis, secret detection and SBOM generation, then files every risk with its remediation context in the same Findings queue as your application and API testing. No pipeline change. Nothing to install.
Pipeline tools only see the code that has a pipeline. Scanners never see the code at all.
Most code security lives inside CI. Repositories without a pipeline, the legacy service nobody deploys any more and the internal tool that never got a job receive no coverage, and they hold the oldest code. Where a pipeline exists, every tool reports into its own console, so dependency alerts, leaked secrets and the weaknesses in the application's own logic are triaged in three different places, by three different people, against three different clocks.
Code Security turns that into one motion. WASViking reads the code, correlates it with what your scans already know about the running application, and files the result where the team already works: the Findings queue, the risk score, the alerts and the tickets.
[clone] acme/payments-api @ 3f9c2e1, default branch, isolated workspace
[sast] 18 security-relevant files selected, 4 weaknesses with evidence
[deps] 212 components, 9 vulnerable, 1 in CISA KEV
[secrets] 1 hard-coded credential, evidence redacted
[sbom] CycloneDX recorded, drift since last run: +3 components
→ 14 findings filed, 2 reopened, 1 resolved on its own
→ workspace deleted, run record kept
Four analyses on every monitored repository, one set of findings.
Each run clones the default branch into an isolated, short-lived workspace on a dedicated worker. Nothing from the repository is ever executed. The clone and every intermediate file are deleted at the end of the run; only the findings, the component list, the redacted evidence and the run record stay.
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 comes with the file and line, the route and parameter, why it is exploitable, an attack scenario and the fix for that exact code.
Evidence anchored to real code
Each reported line is verified against the real file before it reaches you. A weakness the analysis cannot ground in the code is discarded, so a developer never opens a finding that points at code that is not there. The evidence panel shows the excerpt with the vulnerable line highlighted.
Dependency analysis
Dependency manifests for npm, pip, go, composer, Maven and gem become a component list matched against OSV and the CISA KEV catalogue, with drift detection against the previous scan of the same repository. A KEV match is called out on the row, because it is the one to fix first.
Secret detection
The working tree is scanned for hard-coded credentials on every run, and the full git history of the default branch when you switch it on for a repository. Evidence is redacted before it is stored. Findings land next to the DAST and SAST findings of the same application.
SBOM on every scan
Each run produces a CycloneDX SBOM for the repository. It feeds the daily re-check of Supply Chain Intel against new advisories and can be exported as a signed SBOM Evidence Bundle for a customer or an auditor.
Coverage that widens on its own
Every file carrying an open finding is reviewed again on each scan, and the remaining review budget rotates across the rest of the repository. Monitored repositories are scanned on the plan cadence and right away on a push to the default branch, so coverage grows with every run without anyone scheduling it.
Code and runtime in one queue, so a fix is measured once.
Standalone code scanners report into their own console and stop at the commit. WASViking also runs your external and internal DAST, your API testing and your edge telemetry, so a weakness found in code sits next to the findings of the application that ships it, under the same repository name, the same risk score and the same SLA clock.
Findings with a 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. Severity, risk score, SLA, audit trail, assignment, webhooks and ticketing work exactly as they do for a finding from traffic.
Coverage for the code nobody deploys
No pipeline and no agent are needed, so the legacy service, the internal tool and the repository that never got a CI job receive the same assessment as the flagship application. Coverage is decided by a switch per repository, not by which team owns a build server.
One motion for the pipeline and the platform
Teams that already gate merges with WASViking in GitHub Actions or Bitbucket Pipelines keep doing so. Results from the gate and from the platform merge under the same repository name, one lineage, one drift history and one set of findings.
One answer to the question "is our code secure", with the evidence attached.
Leadership does not ask which scanner found what. It asks whether the code that processes customer data is assessed, whether the risks are known and whether they are being closed. Code Security answers with numbers that hold up: what was reviewed, what was found, what was fixed and when.
One remediation queue
Developers open a finding and see the file and line, the route, the parameter, why it is exploitable and the fix, then close it in the tool they already use. New and reopened findings reach Slack, Teams, Jira, ServiceNow or a webhook through the same rules as every other finding.
Audit-ready records
Every run keeps its trigger, branch, commit, duration and outcome. The repository report lists every open finding by engine, including the SAST section, in a PDF a code owner or an auditor can read. The SBOM Evidence Bundle proves what the software contains.
Minutes from connect to first result
Install the WASViking GitHub App or approve the Bitbucket consumer, switch Monitored on for the repositories that matter, click Scan now. The first results are on the page while you are still on it, and the cadence takes over from there.
Evidence mapped to the controls your auditor already asks about.
Secure development, code review, component inventory and vulnerability management are named controls in every major framework. Code Security produces the per-repository, per-run record those controls expect.
| Framework | Control | What Code Security contributes |
|---|---|---|
| PCI DSS v4.0 | Req 6.2.3 bespoke and custom software reviewed before release · Req 6.3.1 vulnerabilities identified and ranked · Req 6.3.2 inventory of bespoke and custom software and third-party components | SAST findings with source-level evidence and severity, ranked dependency vulnerabilities with KEV context, and a CycloneDX SBOM per repository refreshed on every scan |
| ISO 27001:2022 | Annex A.8.25 secure development life cycle · A.8.28 secure coding · A.8.8 management of technical vulnerabilities | A continuous, dated record of code assessment per repository, with each weakness tracked from detection through regression to resolution |
| NIST SSDF (SP 800-218) | PW.7 review and analyze human-readable code · PW.4 reuse of well-secured software · PS.3 archive and protect each software release | Automated code analysis on every run, component provenance with vulnerability matches, and an SBOM kept per scan |
| OWASP Top 10 · ASVS | A01 Broken Access Control · A02 Cryptographic Failures (hard-coded secrets) · A06 Vulnerable and Outdated Components | Every finding carries its CWE and OWASP mapping, so the report reads in the vocabulary the assessor expects |
| LGPD · GDPR | Article 46 · Article 32 technical and organisational measures | Demonstrable, dated evidence that the code processing personal data is assessed continuously and that identified weaknesses are closed |