Code SecurityNew
LimaCharlie Code Security scans the source repositories behind your cloud estate and puts every finding into the same risk-ranked worklist as your cloud posture, identity, and attack-path findings. Dependency, secret, infrastructure-as-code, SAST, container, license, and end-of-life findings are triaged the same way as a public bucket, and the same automation events fire. Because Code Security traces each image back to its source and checks what your workloads actually run, a fix reaches verified only when every in-scope deployment runs it and nothing in scope still runs the vulnerable digest.
Connect a repository
Connect GitHub, GitLab.com, or Bitbucket Cloud from Cloud Security in the console. On GitHub, the console creates the GitHub App for you and turns scanning on in about ten minutes. GitLab and Bitbucket connections ask for read-only scopes. A Set up code security checklist shows each capability, what is blocking it, and the setting that fixes it.
Scan in a sandbox that keeps nothing
A fetch job downloads the commit, and a separate sandboxed container scans it and is then destroyed. Both run in your organization’s data region. The scan container has no cloud identity, a read-only filesystem, and network access only to LimaCharlie storage and the vulnerability database mirror. Eight engines run against each commit: dependencies, malicious packages, secrets, infrastructure as code, SAST, container images, licenses, and end-of-life runtimes.
Rank with exploit data
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 nobody exploits. The Priority fix queue lists the dependency upgrades that close the most findings at once, and code findings appear on the Risks page with Repository and Code source filters.
Trace images to source
Every image-to-source link states how it was established. Inferred means the image’s build steps and files match a connected repository. Asserted means a label or build record names the source without a trusted signature. Verified means a signature was checked for that exact digest, from Google Cloud Build, GitHub Actions attestations, or a signing identity in your provenance_trust policy. Conflicting evidence is reported as ambiguous, and code-to-cloud matches are made only on an exact identifier.
Act through approved remediation runs
Fix pull requests, notifications, tickets, temporary detections, and endpoint isolation all run as remediation runs. A person or API key with cloudsec.respond approves each run, the server derives its target from the finding, and the outcome returns through an authenticated callback. Temporary controls expire on their own after at most 7 days, or 4 hours for isolation, and a HIGH finding opens if a control cannot be removed on time.
Verify and watch for regression
A fix reaches verified when every in-scope deployment has fresh, complete evidence and every running digest carries an uncontested build record naming the fix commit. Image fixes also need a completed scan of each fixed digest that no longer reports the issue. Runtime checks report not_observed only when every sensor on the resource sent a complete telemetry window. If the vulnerable digest runs again within 30 days, the run becomes regressed.
Pull-request checks and AutoFix
On GitHub, Code Security rescans on every push and checks pull requests before they merge. Checks block a merge only when you configure them to. In risk_summary mode a check shows counts and yes/no facts with no resource names, account IDs, IP addresses, or sensor IDs, so a developer sees the verdict without seeing your estate. AutoFix opens pull requests that upgrade vulnerable dependencies, and each write uses a token limited to what that one action needs.
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 has a downloadable SBOM, and findings are available through the console, the CLI, and the API.
How your code is handled
Scanning code means reading it, and LimaCharlie keeps none of it. The scanner never holds your source-control credential, and on GitHub each fetch token covers one repository and expires within an hour. Only findings, the SBOM, and hashes leave the sandbox. Findings never hold file contents, diffs, or secret values, and secrets are stored as a salted hash. Terraform state and plan files are refused outright.
Built for service providers
Code Security inherits LimaCharlie’s multi-tenant architecture. Every record is keyed to its organization and every API route checks the caller against it, so each client’s code findings stay in that client’s tenant alongside its cloud and endpoint data. Coverage is reported per organization with its denominator, and no percentage is shown when the denominator is unknown.
What it costs
Code Security is part of the Cloud Security extension, and subscribing to the extension is the purchase. Paid usage costs $0.80 per protected repository per month, billed daily on that day’s protected-repository count, plus the Cloud Security base fee. Organizations with a sensor quota of 2 or less get a 14-day trial with up to 2 provider connections, 10 repositories per connection, and 5 container images.
Where it sits
Code Security reports risk and verifies fixes, and every action that changes your systems waits for a named approver. LimaCharlie never merges, deploys, rolls back, or revokes credentials for you. A finding without a runtime observation is treated as unconfirmed, never as unexploitable. Deployment tracing to an image digest covers Cloud Run and GKE today.
Connect a GitHub, GitLab.com, or Bitbucket Cloud repository, or walk through it with a solutions engineer.
Start freeBook a demo