Code Security
Find it, prioritize it by real exploitability, gate the release, and open the fix PR.
What does Offload Security's code security (SAST, SCA, secrets, IaC) cover?
Repository and uploaded-code scanning across every layer — static analysis, dependencies, secrets, infrastructure-as-code, and supply chain — turned into governed, auditable release decisions with fix automation.
Code Security in the Offload Platform
What this replaces
Application security findings pile up in scanner outputs nobody owns: unreachable dependency CVEs drown the exploitable ones, secrets slip through, and 'did we ship it anyway?' has no auditable answer.
What Offload does
Repository and uploaded-code scanning across every layer — static analysis, dependencies, secrets, infrastructure-as-code, and supply chain — turned into governed, auditable release decisions with fix automation.
What you get
- SAST (OpenGrep, Bandit, optional SonarQube) with in-context code excerpts on every finding
- SCA backed by OSV.dev and Grype, enriched with CISA KEV and EPSS on every finding
- Known-malicious package detection (OpenSSF MAL advisories) and typosquat detection — both can block release
- Import-level reachability classification to cut dependency noise (advisory; never weakens the gate)
- Secrets detection with Gitleaks (~150 curated rules + entropy, plus platform rules for current LLM-provider keys) across the working tree and the last 200 commits of git history — each secret validated live against its provider so an active credential is never triaged as noise
- Push protection: the same detectors as an API for pre-commit hooks and CI steps, so a secret is stopped before it reaches the remote
- Custom rules for SAST, secrets and IaC from a directory on the host — validated per file and picked up on the next scan, no restart
- IaC scanning with Checkov: Terraform, CloudFormation, Kubernetes, Dockerfile, Helm
- Pull-request review on GitHub, GitLab and Bitbucket: only the changed files are scanned, new findings are separated from pre-existing ones, inline comments land on the diff, and the check is pinned to the exact commit
- Deterministic, versioned release gates enforceable as required checks — GitHub check runs, GitLab and Bitbucket commit statuses — decided from the scan's own findings
- Automated fix pull requests — pushed to a dedicated fix branch, never the base branch — and, opt-in, agent-authored fixes that are re-verified on the merged commit before a finding is marked fixed
- Governed triage: risk acceptance with owner/justification/expiry; false positives with reviewer evidence; decisions scoped to the repository they were made in unless explicitly applied team-wide
- A Suppressions view of everything hidden — by rule, since when, until when — with one-click revoke
- GitHub, GitLab and Bitbucket with encrypted tokens; ZIP upload for air-gapped code; CI/CD API keys
How it works
Repositories are shallow-cloned into an isolated, scan-scoped workspace with hardened git settings; scanners run locally and the workspace is deleted when the scan completes — on success and on failure. Only findings and small per-finding code excerpts are retained, never the source tree.
Release-gate evaluation is deterministic and policy-versioned: the same scan against the same policy always yields the same pass/review/fail decision, with blocking rule identifiers recorded — an audit-defensible answer to 'why did this ship?'.
One platform, one risk view
Code findings share the unified vulnerability queue, mint supply-chain and license violations into the risk register, and appear alongside cloud and Kubernetes findings in a single per-repository report.
Ready to implement it?
Step-by-step guides in the product documentation — every connection is read-only, with copy-paste setup.
Solutions built on Code Security
SaaS & Technology
Code-to-cloud coverage with release gates in CI, SBOMs your enterprise customers ask for, and security-questionnaire automation that turns procurement reviews from weeks into hours — all in one governed risk view.
SBOM & license governance
Generate, ingest and police SBOMs, classify licenses into six families with a policy gate, and produce NOTICE files legal can ship — so supply-chain questions have an answer before due diligence asks them.
Other modules on the platform
Unified Vulnerability Management
One queue, one lifecycle, one history — across every scanning domain.
Cloud Security (CSPM)
Continuous multi-cloud posture across AWS, GCP, and Azure.
Dynamic Application & API Security Testing (DAST)
Test running web apps and APIs the way an attacker would — authenticated, in one pass.
Code Security — frequently asked questions
Which code scanners does Offload Security run?
SAST (OpenGrep, Bandit, optional SonarQube), SCA (OSV.dev + Grype, enriched with CISA KEV and EPSS), secrets detection (Gitleaks over the working tree and git history, with each secret validated live against its provider), and IaC scanning (Checkov for Terraform, CloudFormation, Kubernetes, Dockerfile and Helm). Your own SAST, secrets and IaC rules can be added from a directory on the host.
Can Offload block a release with vulnerable code?
Yes. Deterministic, policy-versioned release gates can be enforced as required checks on GitHub, GitLab and Bitbucket, decided from the scan's own findings, and known-malicious or typosquatted packages can block release outright.
Does Offload review pull requests?
Yes. On GitHub, GitLab and Bitbucket a pull or merge request gets its own review: only the changed files are scanned, new findings are separated from pre-existing ones, comments land on the diff, and the status is pinned to the exact commit it was produced from.
Does Offload open fix pull requests?
Yes — automated fix PRs are pushed to a dedicated fix branch, never the base branch, so remediation is reviewable. Optionally an agent can author the fix; the platform then re-scans the merged commit and only marks the finding fixed when the scanner that found it no longer reports it.