Your own code as the vulnerability: AI code scan in the pipeline
An SBOM shows which third-party components are in your software and which of them have known vulnerabilities. It says nothing about the code your team writes itself. Yet that is where many vulnerabilities come from: a forgotten access check, an SQL query built from user input, a token in a log. Secupipe's AI code scan checks that code automatically in your pipeline.
What the code scan finds
An AI agent reads your repository the way an experienced reviewer would. It starts where the risk is highest: network inputs, authentication, database access, files, cryptography. Typical findings:
- Injection: queries or commands assembled from user input.
- Missing access checks: an endpoint that returns data without checking who is asking.
- Access to other tenants' data: in multi-tenant systems, a query without a filter on the caller's own company.
- Secrets in the wrong place: hard-coded keys, or tokens that end up in logs.
Two passes against false alarms
Scanners that report hundreds of hits are ignored after two weeks. That is why the code scan works in two passes:
- Search: the agent reviews the code and collects suspected issues. It re-checks findings that are already known: still present, or fixed?
- Verification: a second pass tries to disprove every new finding. Anything that cannot be substantiated is dropped.
Only findings with at least 60% confidence are sent to Secupipe. The same location is not reported twice, even if the line moves. And a finding you assessed as a false alarm is not reported again.
Where the findings go
Code findings appear in Secupipe in the same list as the findings from the SBOM: with severity, file, line, function, description and a recommended fix. They get the same deadline, the same VEX assessment, the same alert in Slack or Teams and, if you like, a Jira ticket. On GitHub, new findings also show up as an annotation right at the line in the pull request.
If the agent believes an old finding has been fixed, that is only a suggestion at first. It takes effect once a human approves it.
Your code stays with you
- The scan runs as a container on your CI runner, not on our servers.
- Secupipe sees no source code. Per finding, only the CWE, file, line, function, description and recommendation are reported.
- The agent is read-only: it changes no files and runs no code from your repository.
- The source code goes to the AI provider whose key you supply yourself: Anthropic directly, or via Amazon Bedrock or Google Vertex in an EU region.
We tried it on ourselves first
Since 10 November the code scan has been running on Secupipe's own code: on the changed files with every change, and on the whole repository every Monday. In the very first runs it found real weaknesses, which we fixed:
- A rate limit could be bypassed because the caller's address was read from a header the caller could set.
- Invitation tokens appeared in the access log as part of the URL (CWE-532).
Neither is something a match against vulnerability databases would ever have found. They were in our own code.
How to set it up
The code scan is part of the AI module (from the Team plan). On GitHub Actions one job is enough:
jobs:
codescan:
runs-on: ubuntu-latest
container: ghcr.io/costa-chown/secupipe-autofix:1
steps:
- uses: actions/checkout@v5
with: { fetch-depth: 0 }
- run: secupipe-codescan
env:
SECUPIPE_TOKEN: ${{ secrets.SECUPIPE_TOKEN }}
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
REPO: ${{ github.repository }}
FAIL_ON: hoch
In pull requests the scan checks only the changed files, otherwise the whole repository. With FAIL_ON: hoch (high) the run fails as long as open findings of that severity or above exist. The same container works for GitLab CI and other systems; the instructions are in the app under Pipelines.
And what happens after a finding? The next step is described in our post Vulnerability found, pull request opened.
Start for free Check an SBOM for free