LimaCharlie Code Security marks a fix verified only when production runs it

Most code scanners stop at a merged pull request. LimaCharlie Code Security keeps going until the fix is running.

Code Security is now generally available in the LimaCharlie Cloud Security extension. It scans GitHub, GitLab.com, and Bitbucket Cloud repositories, ranks code findings next to your cloud risk, and checks every fix against what your workloads actually run.

The finish line most code tools draw is wrong

Most code security tools declare victory at merge. A developer bumps a vulnerable dependency, the scanner marks the finding resolved, and the dashboard turns green.

The container built from the old commit keeps running until someone redeploys the service. Security operations inherits that gap. When the exploit attempt lands, the analyst opens the scanner and finds a closed ticket for a vulnerability that is still live in production.

We built Code Security around a stricter rule. A fix counts as verified only when the fixed code runs everywhere in scope and nothing in scope still runs the vulnerable image. Until then, the finding stays open, and the console tells you exactly what evidence is missing.

What ships today

Code Security scans the source repositories behind your cloud estate and puts every finding into the same risk-ranked worklist as your cloud findings. A leaked credential gets triaged like a public bucket, and the same automation events fire.

It connects to GitHub, GitLab.com, and Bitbucket Cloud. Eight engines run against each repository:

Dependency findings name the package, the installed version, and the version that fixes it. Ranking uses EPSS and CISA KEV, so a known-exploited advisory sorts above a high CVSS score that nobody exploits.

On GitHub

Code Security rescans on every push, checks pull requests before they merge, and opens AutoFix pull requests that upgrade vulnerable dependencies. The Priority fix queue shows the dependency upgrades that close the most findings at once.

Bring your own scanner

Teams with an existing pipeline can scan in their own CI and push SARIF and CycloneDX results into the same worklist. Every repository also has a downloadable SBOM.

How a finding travels from commit to cloud

Every step in the chain states how confident it is, and none of them fills a gap with a guess. When evidence is incomplete, Code Security reports unknown, partial, or present along with a reason code.

1. Scan in a sandbox that keeps nothing

A fetch job downloads the commit, and a separate sandboxed container scans it and is destroyed. The scanner never holds your source-control credential, and on GitHub the fetch token covers one repository and expires within an hour. The scan produces findings, the SBOM, and hashes, and secrets are stored only as a salted hash. The data handling page lists what is kept and for how long.

2. Link each image to its source, with a confidence label

An inferred link means the image's build steps and files match a connected repository. An asserted link comes from a label or build record without a trusted signature. A verified link requires a checked signature for that exact digest, from Google Cloud Build, GitHub Actions attestations, or a signing identity you trust. Conflicting evidence is marked ambiguous.

3. Check what is actually running

Runtime checks report not_observed only when every sensor on the resource sent a complete telemetry window. Missing or late telemetry produces present or unknown, with a reason. Code-to-cloud matches happen only on an exact identifier.

4. Act through approved remediation runs

Fix pull requests, notifications, tickets, temporary detections, and endpoint isolation all run as remediation runs. A named person or API key with the cloudsec.respond permission approves each one, and the outcome returns through an authenticated callback. Temporary controls expire within 7 days, or 4 hours for isolation. LimaCharlie never merges, deploys, rolls back, or revokes credentials on your behalf.

5. Verify, then watch for regression

A fix reaches verified when every in-scope deployment runs a digest whose build record names the fix commit. For image fixes, a fresh scan must also confirm the issue is gone. If the vulnerable digest runs again within 30 days, the run flips to regressed.

Deployment tracing to an image digest covers Cloud Run and GKE today. The full rules are on the What Code Security guarantees page.

Who gets the most out of it

Security operations teams

Code findings land on the same Risks page as cloud findings, with Repository and Code source filters to narrow the list. Analysts work one queue, and the automation events they already rely on fire for code findings too.

MSSPs and MDR providers

Code Security adds application risk to the service you already run in LimaCharlie, with each client's data keyed to its own organization. Pull-request checks in risk_summary mode show counts and yes/no facts with no resource names, account IDs, or IP addresses, so developers at a client never see the estate behind the verdict.

Teams running agents

Code Security is available through the console, the LimaCharlie CLI, and the API. Any workflow or AI agent that already operates LimaCharlie through the CLI can pull code findings, open remediation runs, and check verification status without a new integration. Every action an agent proposes still waits for a named approver, so analysts stay in control of what changes.

Get started

Setup takes about ten minutes on GitHub. The console creates the GitHub App for you and turns scanning on. In the console, open Cloud Security, then Code security, and follow the Set up code security checklist. The getting started guide walks through each step.

Code Security is part of the Cloud Security extension, and subscribing to the extension is the purchase. See pricing for current plans and trial details.

Connect your first repository

Sources

• Code Security overview

• What Code Security guarantees